Add Book to My BookshelfPurchase This Book Online

Chapter 5 - Adding Support for Legacy LANs

Cisco TCP/IP Routing Professional Reference
Chris Lewis
  Copyright © 1999 The McGraw-Hill Companies, Inc.

IBM Networking
IBM networking is a topic vast enough to justify the writing of many, many volumes. Here we have only one section in a chapter to give an overview of the most common things a network administrator will have to do when integrating IBM applications over a TCP/IP-based Cisco router network. Typically, Cisco routers are implemented to reduce or totally eliminate the need for IBM front-end processors (FEPs). FEPs direct SNA traffic over a network, typically using low-speed 9600 bps lines. The drive to reduce FEP utilization comes from an economic need to reduce the cost of FEP support and to provide a cost-effective WAN that can deliver client/server IP-based, as well as SNA, applications.
Typically Cisco routers get introduced in an IBM data center via direct channel attachment to replace a FEP and in each remote branch location connected to the data center. The data center router will route IP traffic over the WAN as normal and use a technology called Data Link Switching to transport SNA or NetBIOS traffic over the same WAN. At the remote branch end of the network, a small 2500-series router can be used both to connect LAN workstations to the WAN that can receive IP traffic, and to connect an IBM terminal controller that receives SNA traffic to service local IBM 3270 terminals.
Overview of IBM Technology
Let's face it, all this TCP/IP internetworking stuff may be fun, but what really delivers the benefits of computer technology to an organization is a well-designed, reliable, and responsive application. IBM technology has been the technology of choice for mission-critical applications for the past 20 years and will be with us for many more. The basic reason for this is that it works. With IBM's NetView management system, network managers also have an effective tool to monitor, troubleshoot, and (important for mission-critical applications), guarantee response times of applications.
IBM technology is hierarchical and fits well into an organization that works in a structured fashion, as everything is controlled by a central MIS department. Clearly, in today's faster-moving business environment, such central control with its inherent backlogs is not the favored approach for many organizations when planning future information systems development. Having said that, if an existing application is in place and serving its users well, there is little need to replace it just to make a network manager's life easier. Given that IBM applications will be around for a while, it is more cost-effective to integrate them into a multiprotocol network than to provide a separate network just for that traffic. Let's now look at IBM's communication technology in a little more detail.
IBM Networking Systems.     The most prevalent IBM networking system is the Systems Network Architecture (SNA). SNA is a centralized hierarchical networking model that assigns specific roles to machines within the overall network. IBM mainframe operating systems (such as MVS, VM, or VSE) were designed to have access to an SNA network via VTAM, the Virtual Telecommunications Access Method, which defines which computers will connect to which applications. Applications in this environment are written to interface to VTAM through Logical Unit (LU) sessions. LU sessions are established, terminated, and controlled via a VTAM function called the System Services Control Point (SSCP). For IBM network staff, the terms LU and PU (Physical Unit) are frequently referenced terms. Defining an LU of 2 identifies a 3270 terminal session, for example. In addition, each type of terminating device (such as a printer or workstation) will have a different PU number associated with it.
IBM networkers are accustomed to having a method by which to allocate specific bandwidth resources to different types of traffic. This is not available as standard within TCP/IP, which relies on vendor-specific features such as Cisco's priority or custom queuing to duplicate that functionality. Being a centralized hierarchy, SNA provides good security with the RACF system, which is not matched very well by any security system currently implemented in the TCP/IP world. Again, TCP/IP standards rely on vendor-specific implementations such as Cisco access lists and TACACS+ (all of these extensions will be covered in subsequent sections).
A totally different IBM architecture is the Advanced Peer-to-Peer Networking scheme (APPN), which was designed for the AS/400 environment. In this architecture, the Logical Unit used is LU6.2, which applications use via a program interface called Advanced Program-to-Program Communication (APPC). Instead of 3270 sessions, the AS/400 operating system uses 5250 sessions to communicate between the server and workstation. A large part of why IBM systems lost popularity was due to these different architectures associated with different hardware platforms. In many organizations, network staff had to implement multiple cabling systems and users needed multiple terminals on their desks to access different IBM systems.
TCP/IP Support Provided by IBM.     IBM mainframe and midrange computers will support TCP/IP connectivity directly via the TN3270 and TN5250 protocols. These protocols allow a user workstation running only TCP/IP communications software to run 3270 and 5250 applications over a TCP/IP network. Most of the functionality required by a user to run IBM applications is provided by the TN3270 and TN5250 protocols; however, some features are missing that might be important to some users.
In TN3270, the print job confirmation feature, important to users such as stockbrokers looking for trade confirmations, is not supported by the TCP/IP LPR/LPD printing mechanism. Also, the SysReq and Attn keys used to swap between mainframe applications is not fully supported under TCP/IP.
In TN5250, most terminal emulation, printing, and file-sharing functions are available, but file transfer has been a problem. APPN allows sophisticated querying of DB2 databases to retrieve data. With TN5250, there are no APPN functions, so it is much more difficult to retrieve query output from a DB2 database.
IBM has resolved these problems with a technology called Multiprotocol Transport Networking (MPTN). Using this technology, an APPC application can communicate over a TCP/IP network without the need for client workstations to load multiple protocol stacks. IBM achieves this by use of an application call translator that maps APPN to TCP/IP sockets function calls.
With an introduction to the IBM technology and an idea of some of the problems, let's look at how Cisco deals with them.
Cisco's Approach to IBM Technology Integration
If you decide to integrate IBM technology onto a multiprotocol network, the biggest concern of those responsible for delivering IBM application support is that they will lose the ability to guarantee response times. Typically, SNA applications have predictable low bandwidth consumption, whereas TCP/IP protocols are typified by bursts of traffic, often generating a need for high bandwidth availability. To alleviate these fears, Cisco implemented priority output queuing, which enables network administrators to prioritize traffic based upon protocol, message size, physical interface, or SNA device. If this mechanism is deemed inadequate, Cisco's custom queuing allows specific bandwidth to be allocated to different types of traffic, in effect providing separate channels on the one link for the different types of traffic carried.
Direct Channel Attachment.     Let's take an overview of channel attachment, as shown in Fig. 5-19. In an IBM mainframe, Input/Output Processors (IOPs) communicate between the main CPU and the mainframe channel, which is an intelligent processor that handles communication with external devices. The Cisco Channel Interface Processor (CIP) can connect directly to a mainframe channel for high-speed communication between a mainframe and a router network. A CIP in a Cisco router replaces the need for an IBM 3172 controller to provide communication for terminal and printer devices. Channel attachment technologies that Cisco supports for CIP implementation are as follows:
  ESCON, a fiber optic link between an ES/9000 mainframe channel and the CIP.
  Parallel bus-and-tag for connecting to System 370 and subsequent mainframes.
  Common Link Access for Workstation (CLAW), which enables the CIP to provide the functionality of a 3172 controller.
Figure 5-19: Connecting a mainframe and router via channel attachment
The CIP works in conjunction with an appropriate interface adapter card, the ESCON Channel Adapter (ECA) for fiber connection, or the bus-and-tag Parallel Channel Adapter (PCA). One CIP supports two interface cards and up to 240 devices. When installed in a Cisco router, the CIP can be configured much like any other interface. The CIP will use TCP/IP to communicate with the mainframe channel, so the mainframe needs to be running TCP/IP. If the mainframe has VM for an operating system, it must be running IBM TCP/IP for VM version 2, release 2; if it is running MVS, it must support IBM TCP/IP for MVS version 2, release 2.1.
To get the CIP up and working, a compatible configuration must be entered into the CIP interface and the IBM channel. Before we look at those configurations, it should be noted that the CIP can be installed only in a modular Cisco router. The modular series routers (the 4x00- and 7x00-series) are supplied as a chassis in which modules with different interfaces can be installed. The 2500-series routers come with a fixed configuration and have no slots for additional cards to be installed. So far, configurations given for routers have assumed a 2500-series router.
To configure an interface for a modular router, we first need to specify the slot number of the card. For example, if we have a four-interface Ethernet module inserted in the slot 0 of a 4700 router, the Ethernet interfaces will be addressed as Ethernet 0/1, Ethernet 0/2, Ethernet 0/3, and Ethernet 0/4. All show and interface configuration commands must reference the specific slot and Ethernet interface in this way. The same is true of a CIP card. The following shows how to select port 1 of a CIP interface card in slot 0:
Router1(config)#interface channel 0/1
Router1(config-int)#
Now that the router is in configuration mode for the CIP interface connected to the IBM channel, a basic configuration can be input to establish IP communication between the IBM channel and the CIP. The configuration commands to define a router process, and assign an IP address and CLAW parameters are shown as follows:
router eigrp 30
network 172.8.0.0
network 173.2.0.0
!
interface channel 0/1
ip address 172.8.5.1 255.255.255.0
claw 01 0 173.2.6.4 MVSM/C D100 tcpip tcpip
The CLAW parameters are not obvious and should be configured with help from a Cisco Systems engineer. Essentially, the CLAW arguments can be defined as follows:
  The 01 is the path that is a value between 01 and FF, which is always 01 for an ESCON connection.
  The next 0 value is a device address from the UNITADD value in the host IOCP file and should be obtained from the IBM host administrator.
  The rest of the values are derived from the Device, Home, and Link values from the host TCP/IP configuration files and refer to the host IP address, host name, device name, and host and device applications.
Once operational, the CIP can be monitored and controlled much the same as any other interface on a Cisco router. All the usual show interface, show controller, and shutdown/no shutdown commands work in the same fashion as for Ethernet or serial interfaces.
STUN and DLSw.     Cisco's Serial Tunnel (STUN) feature was designed to allow IBM FEP machines to communicate with each other over an IP network. STUN encapsulates the SDLC frames used to communicate between FEPs within an IP packet for transmission over an IP internetwork. This provides flexibility in internetwork design and enables SNA and IP traffic to share the same wide area links, reducing costs and simplifying management. DLSw, which stands for Data Link Switching, provides a method for encapsulating IBM layer 2 LAN protocols within IP packets.
Using STUN to Interconnect FEP Machines.     The most popular implementation of STUN provides local acknowledgment between the router and the FEP, to keep this traffic off the WAN. This does, however, require knowledge of the Network Control Program (NCP) SDLC addressing scheme setup in the connected FEP. Figure 5-20 shows how FEPs are connected with and without STUN-enabled routers between them.
As you can see, the Serial 0 port on both router 1 and router 2 takes the place of a modem that previously connected to the FEP. This means that the FEP is expecting to connect to a DCE device. Therefore the router-to-FEP cable must have the configuration that sets the router port as a DCE, and we must enter a clockrate command in the configuration of interface Serial 0, just as we did in the original lab setup in Chap. 3 when we were connecting two router ports directly together.
Before we see the configurations for router 1 and router 2, let's discuss what we need to achieve with the configuration.
Figure 5-20: Connecting STUN-enabled routers between IBM FEPs
STUN-enabled routers communicate on a peer-to-peer basis and we need some way of identifying each router to its STUN peer or peers. This is achieved by defining a peer name for each router. The peer name is defined as one of the IP addresses of an interface on that router. Typically a loopback interface is defined, and the address of the loopback interface is used as the router peer name. The reason for this is that loopback addresses are up only as long as the router is up; if we gave the router a peer name of one of the serial interfaces, the peer name would become invalid if the serial interface was down for any reason.
Next, all the STUN peers that need to communicate as a group must be assigned the same STUN protocol group number. STUN peers will not exchange information with peers in another group number. The stun protocol-group command also defines the type of STUN operation for the link. The most popular option is the SDLC option, which provides local acknowledgment to the FEP and keeps this traffic off the serial link. The other popular option is the basic option of this command, which does not provide local acknowledgment, but does simplify router configuration slightly.
Using the SDLC option of the stun protocol-group command necessitates configuring the serial port connected to the FEP with an appropriate SDLC address number, which should be provided by the IBM FEP administrator. This option provides local acknowledgment of link-level packets, and therefore reduces WAN traffic. Once the SDLC address has been defined, we need to use the stun route address x interface serial y command, where x is the SDLC address number and y is the serial port through which you wish to direct STUN-encapsulated FEP frames. A stun route address ff interface serial y command directs broadcast SDLC traffic through the same STUN-enabled interface.
A typical STUN configuration for router 1 and router 2 in Fig. 5-20 is shown in Fig. 5-21.
Figure 5-21: Router 1 and router 2 configuration from Figure 5-20
  Bridge hop-count limit of 7.
  Excessive generation of broadcast explorer packets, consuming WAN bandwidth.
  Unwanted timeouts at the Data Link level over WAN links.
It is important to realize that DLSw is not a layer 3 protocol and therefore does not perform routing. DLSw is a layer 2 protocol and works on the basis of establishing a DLSw circuit between two routers in an IP network. When DLSw is implemented, local Data Link level (layer 2) communications are terminated at the local router, enabling that router to provide link-level acknowledgments. This functionality effectively turns a connection between two machines communicating via a DLSw router pair into three sections. At each end of the link, the machines will establish a connection with the DLSw router (typically a source route connection), and the two DLSw routers will establish TCP connections to carry the traffic over the IP WAN. In Fig. 5-22, PC A exchanges link-level acknowledgments with router 1, and PC B exchanges link-level acknowledgments with router 2; router 1 and router 2 exchange DLSw information via TCP connections.
Figure 5-22: The three links used to establish a DLSw connection over an IP network
In fact, before it is possible to switch SNA or NetBIOS traffic between two DLSw-enabled routers, these routers must establish two TCP connections. Once the TCP connections are established, various data will be exchanged between the routers, the most noteworthy of which are the MAC addresses and NetBIOS names each router can reach. So how does DLSw direct traffic through an IP network?
The process is essentially the same for both SNA and NetBIOS switching. Both protocols will seek out the location of a destination by some type of explorer packet sent out on the network. The explorer packet asks all devices if they can get to the desired destination. One of the DLSw routers on the IP network should respond that it can reach the destination, at which time the TCP connections between the routers are made, and the packet can be sent from source to destination over the IP WAN.
There are many permutations and combinations of possible interconnects that might need to be made via DLSw links. We shall examine the example of connecting a remote Token-Ring LAN to a central SDLC IBM controller here, and in the next section on Windows NT, we will look at the example of connecting two Ethernet segments together via DLSw, so that NetBEUI traffic can be switched over an IP WAN.
The example shown in Fig. 5-23 is of a DLSw implementation that connects an SDLC controller to a remote Token-Ring LAN via an IP WAN.
Figure 5-23: Using DLSw to connect an SDLC controller to a remote token ring
Let's discuss the configuration commands implemented one by one.
Command source-bridge ring-group 1000 defines a DLSw router group. Routers will establish DLSw connections only with other routers in the same ring group.
  Command dlsw local-peer peer-id 180.4.1.1 enables DLSw on the router and gives the router a DLSw ID, which is taken from the loopback address defined, just as was done for STUN in the previous section.
  Command dlsw remote-peer 1000 tcp 180.4.3.2 identifies a remote peer with which to exchange DLSw information using TCP. In this command, the 1000 value is the ring-group number and must match that set by the source-bridge ring-group command.
  Command sdlc vmac 1234.3174.0000 sets a MAC address for the serial port connecting to the SDLC controller. This is a necessary part of enabling the link-level addressing for DLSw, enabling complete source-to-destination addressing using link-level addresses.
  Command sdlc role primary sets this end of the link as the primary.
  In command sdlc xid 06 12345, XID requests and responses are exchanged prior to a link between the router and the controller reaching an up state. The XID is derived from parameters set in VTAM and must be determined by the IBM administrator.
  Command sdlc partner 1234.5678.9abc 06 defines the MAC address of the token ring on the remote router that will be communicated with, and the SDLC ID number of the link connecting the two DLSw routers together.
  Command sdlc dlsw 5 associates the DLSw and SDLC processes, so that DLSw will switch SDLC ID 5 traffic.
  Command source-bridge 5 4 1000 enables source routing for the token ring attached to router 2 and defines the token ring as ring number 5, router 2 as bridge number 4, and the destination ring as number 1000.
  Command bridge 8 protocol ibm defines the spanning tree algorithm for this router and associates it with an ID of 8.
  Command source-bridge spanning 8 identifies all the Token-Ring ports that will participate in defining the spanning tree for the Token-Ring side of the network.
As you can see, this type of configuration is not trivial and takes significant cooperation between IBM data center staff and those responsible for Cisco router management.

 


 
Books24x7.com, Inc © 2000 –  Feedback